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ABSTRACT 


Military system acquisition management decisions can be both 
untimely and uninformed, according to the author, due to the 
adverse effects of communication breakdown and filtering of 
information. An acquisition group decision support system 
(AGDSS), defined in this thesis, seeks to maintain acquisition 
team integrity and provide the necessary information processing 
capacity to mitigate the impact of these effects. The combina- 
tion of such key technologies as local area networks, word 
processing, graphics, data base management, and video confer- 
encing, is employed, which can free acquisition team members of 
mundane paperwork and afford them extraordinary decision making 
capabilities. These capabilities promise to result in more 
timely and better informed decisions. An example is provided to 
illustrate the application of an AGDSS to an acquisition-related 
problem and to show the benefits that can be derived from the 
output of the AGDSS. Finally, a system-level specification 
describing the performance and interface requirements is pre- 


sented. 
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I. ACQUISITION GROUP DECISION MAKING 


Military system acquisition management decisions are 
made on a variety of programmatic issues related to program 
management and functional areas, such as configuration man- 
agement, contracting, engineering, logistics, manufacturing, 
program control, and test. Examples include the approval of 
a design change, the procurement of additional spare parts, 
the setting of production increments, the approval of func- 
tional and physical configuration audits, the synthesis of 
budget forecasts, and the exercise of contract options. 

The above decisions are acknowledged by the Defense 
Systems Management College to be usually made by consensus 
(Sellers, 1985, p. 1.5d), because the program manager or his 
functional managers cannot make a decision in one functional 
area, such aS an engineering issue, without a collateral 
impact on one or more of the other functional areas. In 
addition, time and money are two constraints that enter into 
the decision making process. There is never enough of 
either one. Acquisition schedules all too often are overly 
ambitious and, as such, are unrealistic, resulting in less 
than optimum decisions. Where Research & Development (R&D) 
is involved, there is little knowledge, if any, of the true 
capabilities of a contractor to support the R&D activity 
within the time and budget allotted. Furthermore, schedule 
slips and cost overruns incurred during R&D tend to compli- 


cate the time and money constraints associated with produc- 





tion. Occasionally, the acquisition team members are absent 
or preoccupied with other programs (as is common with ma- 
trixed organizations), and decisions are made without a full 
team's consent. Frequently, the entire team must be gath- 
ered together for discussion and/or be engaged in extensive 
research-discussion cycles. The latter can result in weeks 
of deliberation which may lead to other problems. Absence 
of team members and lengthy deliberations provide for what 
the author defines as untimely and/or uninformed decisions. 
Program management decisions generally result from a 
collection of inputs and or factors (Sellers, 1985, 1.5c) 
which are in and of themselves time sensitive in most if not 
all cases. Because the circumstances governing the decision 
making process(es) are varied, subject to change, and in 
some instances nondeterministic, a structured environment 
does not lend itself well to providing a feasible approach i 
to problem resolution. For instance, a manager is briefed 
regularly on the functional status (engineering, logistics, 
manufacturing) of his or her program. Each functional area, 
albeit an integral part of the remaining areas is segregated 
for management oversight. Despite the manager's skill to 
delegate to his or her functional experts, the segregation 


of responsibility leads to the occurrence of "holes" in the 





management umbrella. Things inevitably "slip through the 


cracks", either because the dispersion of program team 


members within a matrixed organization causes communication 











breakdown or because unforeseen events occur. TWLikewise, the 


program manager is routinely responsibile for reporting a 
program's status regarding such issues as funding, sched- 
ule(s), and progress on resolution of test discrepancies to 
his or her boss* (Sellers, 1985, p. 1.5c). When a program 


is in its infancy, all indicators are generally satisfactory 





(green). Then as time passes, milestones begin to slide and 
problems begin to surface. If dealt with up front the 
impact of these problems can be reduced. However, more 
often than not, things are neglected or hidden until it is 
too late to capitalize on opportunities beneficial to the 
outcome. This benign neglect can be attributed to the 
inherent nature of the acquisition environment, where a 
preponderence of data, systems, and dynamics of schedules 
necessitates the filtering of information. This filtering 
seeks to limit the quantity of information as well as the 
alternative decisions the decision maker has available. 
Decision outcome(s) is/(are) made based on neither all the 
information available nor the flexibility given by weighing 
the feasible options. Neglecting to consider all the fac- 


tors and options regarding a decision imposes a bias(struc- 


* The term boss shall hereafter be referred to as the 
director of programs, the title given to the author's imme- 
diate supervisor while the author served as program manager. 
The director of programs is a middle management position and 
should not be confused with the newly created executive 
level position of program executive officer (PEO). 

















ture) on the decision making process. This structure may 
lead to an untimely and/or uninformed decision. 

The untimely and/or uninformed decision is an extremely 
common one that to date has repeatedly led to the acqui- 
Sition of systems that did not perform to the intended 
specifications. Not only have systems been accepted into 
the inventory at substandard performance levels, but as a 
result, down the road these systems may acciue a higher life 
cycle cost, or compromise operator safety, and can also 
result in a mutual distrust between government and indus- 
try. 

A group decision support system (GDSS) can provide 
acquisition team decision makers the best information re- 
sources possible with which to formulate and execute their 
decisions. It can do so by maintaining team integrity on a 
Guily basis as well as maintaining corporate knowledge when 
personnel get reassigned. The physical implementation of a 
GDSS is the local decision network (LDN) (see Figure 1, 
Nesanctis and Gallupe, 1985, p.195). The LDN is a local 
area network (LAN) of individual decision support system 
(DSS) terminals. In addition to the standard LAN protocols, 
the LDN requires facilities to control both how and what 
type of information should be exchanged (see APPENDIX p. 2, 
para. 3.1.1.1). Aside from its importance as a communica- 
tions link any further discussion of the LAN portion of the 


GDSS is reserved for the system specification found in the 


Figure 1 Local Decision Network 


APPENDIX. Thus only the DSS is explored further in this 
document. The enhanced capability to seize opportunities as 
well as to seek additional initiatives is facilitated by an 
acquistion group decision support system (AGDSS) (for both 
government and contractor). It can provide for a more 
effective acquisition environmment. 

The AGDSS's primary role would be to both .coordinate and 
facilitate the daily transfer of information among program 
team members and to aid the decision processing needs of the 
program manager and the team. Secondly, the AGDSS would be 
tasked to provide reports to the director of programs as 
required. Finally, the AGDSS would support "what if" type 
decision making, that is foresighted with the goal of deter- 
mining current decisions by which to avert problems down- 


stream. The "what if" capacity of the AGDSS would also be 


helpful in searching for possible schedule slips or other 





program impacts due to potential risk taking on the part of 
the program manager. 

In order to maintain the continuity of corporate knowl- 
edge as personnel are reassigned, the AGDSS would provide, 
via its libraries, repositories of information. Unlike 
traditional Management Information Systems/Electronic Data 
Processing (MIS/EDP) systems, this data will be more poten- 
tially exploitable by the successors of those that create it 
via the flexibility and unstructured design of the AGDSS 


subsystems. 








II. INTRODUCTION TO DECISION SUPPORT SYSTEMS 


A. DEFINITION 

A decision support system (DSS) is an interactive com- 
puter-based system to aid decision makers in utilizing data 
and models toward the solution of unstructured problems 
(Sprague and Carlson, 1982, p. 4). The distinction between 
structured versus unstructured problems is fundamental to 
understanding the difference between traditional computer 
systems and DSS. The former employ structured algorithms 
which must be executed sequentially with little or no oppor- 
tunity for user modification. A DSS, on the other hand, 
affords the user the flexibility to alter both the content 
and sequence of the programs; nence the reason for their 
being characterized as unstructured. The interactive nature 
of the system, to include widespread sharing of data and 
program modules, results in a unique modeling capability 


with a DSS. 


B. THE DSS IN THE INFORMATION WORLD 
1. The Connotational View 
Figure 2 (Sprague and Carlson, 1982, p. 7) shows the 
relationship between three levels of sophistication in the 
information systems world. EDP as the first of these 
continues to perform the basic operations of data storage 


and processing with summary reports (little more than data 





Decision focus 


DSS 


Data 
focus 
EDP 


Figure 2 The Connotational View 








listings) for management as its major product. MIS improved 
on the EDP concepts of planning and integration at the 
operational level, providing middle management with informa- 
tion management via data base capabilities. A need to 
provide executive management with a decision aid remained 
largely unaddressed by EDP/MIS technology. A DSS can pro- 
vide top managers as well as their subordinates, with quick, 
user friendly, and individually tailored decision support. 
2. The Theoretical View 
From a theoretical standpoint a DSS is looked upon 
as: 
Dedicated tc improving the performance of knowledge 
workers...whose primary job...is the handling of inform- 
ation in some form...in organizations through the appli- 
cation of information technology. (Sprague and Carlson, 
1982, p. 8) 
Figure 3 (Sprague and Carlson, 1982, p. 9) depicts ina 
c.assical sense the dimensions of an information system. 
Levels of management are represented vertically and func- 
tional activities are represented horizontally and labeled 
as "Interactive models", where the acronyms OR/MS and 
DC/OA/WP, represent Operations Research/Management Science 
and Data Communications/Operations Analysis/Word Processing 
respectively. 
The third, or systems dimension is comprixed of informa- 


tion systems providing support to the knowledge workers. 


While advances in office automation and telecommunications 


<+— Management level dimension ———___--____—__» 


Transaction processing 





Functional dimension 


Figure 3 The Theoretical View 
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Interactive models 
OR/MS/STATISTICS 


DC/OA/WP 


EDP/MIS 





improve the performance of these systems, the combination 
of information technology and operations research/management 
science via interactive modeling, pushes the evolution of 


the DSS. 


C. VIEWPOINTS 

The process of building a DSS is looked upon from three 
viewpoints; those of the users, the builders, and the tool- 
smiths. The users are concerned with the problem solving or 
decision-making task support that the DSS will provide. The 
builders' interest lies in designing capabilities into the 
DSS to support the users. The toolsmiths involve themselves 
with the integration software to form DSS generators in 
support of the builders. 

From the users' perspective, DSS performance can be 
measured in terms of performance objectives. The builders 
view DSS performance in terms of three characteristics: (1) 
user interface (dialog handling), (2) data base and data 
base management, and (3) modeling and analytic capability. 
The toolsmiths share the builders' view but focus on the 
underlying architecture of these characteriscs. 

1. The User 

The following paragraphs describe six performance 
objectives by which a user measures DSS performance. 
a. Semistructured/Unstructured Decision Support 
EDP/MIS are of little use in this environment of 


underspecified problems where the structure of the decision 


11 








process depends significantly upon the style of the decision 
maker. 
b. Multi-level Decision Support 
Users at all levels of the decision making - 
process require integration and coordination of their ef- 
forts toward total problem solution. 
c. Independent/Interdependent Decision Support 
The former provides a decision maker sole au- 
thority for a decision whereas the latter connotes the 
sharing of the decision making process with others. Sequen- 
tial interdependent decision support is the passing along of 
a decision to successive decision makers for action. Pooled 
interdependent decision support results in arbitration among 
decision makers. 
dad. Multi-phase Decision Support 
Figure 4 illustrates Simon's Intelligence, 
Design, Choice (IDC) paradigm (Sprague and Carlson, 1982, 
p.26), a three-phase decision making model. The double 
headed arrows at the left of the figure indicate a series of 
feedback loops among the phases of this operations process: 
Intelligence - Acquiring information about the 
environment, processing that information for clues leading 
to conditions requiring decision making. 


Design - Problem formulation and testing the 


feasibility of possible solutions. 















DSS 


MS/OR 


Choice 
Implementation 


Figure 4 Phases of Decision Making 






Choice - Choosing from the selection of possible 
solutions and implementing that choice. 
e. Process Independent 
The DSS must have the ability to support a 
variety of decision-making processes. Rather than depend on 
a particular process it must instead, both conform to the 
individual cognitive style of the decision maker and be 


under his or her control. 
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f. Ease of Use 
The DSS must be user friendly and flexible in 
order to attract user allegiance. For unlike the EDP/MIS 
environment, decision makers, by virtue of their position in 
the organization, can refuse to be inconvenienced or intimi- 
dated by a computer system, especially if it doesn't meet 
their needs. 
2. The Builder 

Although the builder has the option to construct the 
DSS from DSS Tools (hardware and software used tc develop 
DSS generators), it is usually more practical to use DSS 
generators possessing initial capabilities which can be 
modified to satisfy the user's needs based on changes in the 


environment, tasks, and the user (see Figure 5, Sprague and 





Environment 






Figure 5 The Decision-Making System 
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Carlson, 1982, p. 28). The initial DSS can be thought of as 


a succession of black boxes containing subsystems within 


each. Referring to Figure 6 (Sprague and Carlson, 1982, 


29), within the DSS box are the data base, model base, 


The DSS 









Data base Model base 


Software 
system 


Environment 


Figure 6 Components of the Decision Support System 
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and a software system which is further comprised of dialog 
generation and management software (DGMS), data base manage- 
ment software (DBMS), and model base management software 
(MBMS) . 

a. The Dialog Subsystem 

While the user, terminal, and software comprise 

the components of this subsystem, the experience (Sprague 
and Carlson, 1982, p. 30) consists of the action language, 
the display or presentation language, and the knowledge base 


(see Figure 7, Sprague and Carlson, 1982, p. 30). The 





Action 
language 


Presentation 
language 


User 


Knowledge 
base 


Figure 7 The Dialog Subsystem 














action language is the means by which the user communicates 
with the system, a mouse or keyboard for example. The 
presentation language is what the user sees such as a screen 
or printer output. Finally, the knowledge base is the 
knowledge the user brings to the system. 
b. The Data Subsysten 

Figure 8 (Sprague and Carlson, 1982, p. 31) 
illustrates the extensions of the DSS data base which sug- 
gest the DSS demands more from its data base management 


system than an EDP/MIS system. In addition to its internal 














External data 
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Figure 8 The Data Subsystem 
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data , the DSS requires data from external sources to ac- 
quire the information necessary for decision making. To 
accomplish this, the data subsystem has a data capture and 
extraction capability for rapid access and update of data. 

c. The Models Subsystem 

The capability derived from this subsystem to 
integrate data retrieval and reporting from EDP with tech- 
niques from the management science arena are what distin- 
guish the DSS's potential from that of its predecessors as a 
decision aid. Figure 9 (Sprague and Carlson, 1982, p.33) 
illustrates the models subsystem component. The models are 
assembled from a set of building blocks much like subrou- 
tines. A set of model management functions similar to those 
of data base management provide the capability to assemble, 
catalog, and interrelate the models quickly and easily. 
3. The Toolsmith 

The toolsmith is invclved with the science and engi- 
neering aspects of information technology in relation to the 
builder's model of DSS previously described. Experimental 
and theoretical work continues in systems requirements for 
dialog management. Improvements in handling both time 
series data and probabilistic data are sought for data 
management. Finally, artificial intelligence (AI) is ex- 
pected to expand upon existing what if modeling capability 
derived from the formulation of interrelationships between 


variables. 
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D. ‘THE REPRESENTATIONS, OPERATIONS, MEMORY AIDS, CONTROL 
MECHANISMS (ROMC) FRAMEWORK 
The (ROMC) Framework provides a process independent 
approach to systems analysis for DSS. 
1. Representations 
Decision makers must physically represent infor- 
mation or media such as paper, blackboards, transparencies, 
etc. to communicate some concept. The following are some 
examples in the IDC format: 
Intelligence 
- Identify problem to be solved 
- Formulate objective function and con- 
straint equations 
- Write the equations 
Design 
- Load and run the equations in a linear 
program 
- Modify the equations 
Choice 
- Compare range of feasible solutions 
- Select the appropriate solution 
2. Operations 


As discussed previously the IDC model describes the 


operations process. The following illustrates some examples 


in the IDC format: 





Intelligence 


Design 


Choice 


3. Memory Aids 


Memory 


State the problem 
Develop a plan 
Organize a team 
Implement the plan 


Manage the plan's implementation 


Conduct fact finding to obtain informa- 
tion 
Organize the information 


Validate the findings 





Evaluate the facts 
List the options 
Consider the associated risks for each 


option 


Compare the risks 
Choose an option 


Justify the choice 





Aids support the use of representations and 


operations as illustrated below: 


A data base from sources internal and external to the 
organization 
Views (aggregations and subsets) of the data base 


Workspaces 
preserving 


for displaying the representations and for 
intermediate results as they are produced 


by the operations 
Libraries for saving workspace contents for later use 
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- Links for remembering data from one workspace or 
library that is needed as a reference when operating 
on the contents of another workspace 
- Triggers to remind a decision maker that certain 
operations may need to be performed 
- Profiles to store default and status 
data (Sprague and Carlson, 1982, p. 104) 


4. Control Mechanisms 
Control mechanisms aid the decision-maker in utiliz- 
ing representations, operations, and memory aids in the 
decision-making process in accordance with their individual 
cognitive abilities. The mechanisms range from menus or 
function keys to help commands and procedures for adding or 


modifying commands. 
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III. THE DESIGN AND IMPLEMENTATION PLAN FOR THE AGDSS 


A. DESIGN CONSIDERATIONS FOR THE AGDSS 
The AGDSS will support an iterative design capability 
with a configuration that is flexibile to change as the 
needs of its users evolve. It will be developed in accord- 
ance with the ROMC framework with the following capabili- 
ties: 
1. Automate the storage, processing, and retrieval of 
documentation 
2. Generate reports, including graphics and spreadsheats 
3. Provide windows containing integrated text, graphics, 
and video displays 
4. Support local area networking 


5. Be easy to use. 


B. SYSTEM CHARACTERISTICS 
The AGDSS consists of computer terminals networked 

together. The acquisition team will use the system to 
conduct group decision making via menu configurations corre- 
sponding to program management and functional area. All 
AGDSS terminals will have identical main menus. The submenu 
configurations fall into three basic categories: 

1. Task menus listing management or functional area tasks 


2. Window setup menus for display of multimedia sources 
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of documentation, correspondence, spreadsheet, graph 
ics, and video. 
3. Communications menus configuring communication modes 


and channels. 


C. AGDSS SUBSYSTEM 
1. The Dialog Subsystem 
a. Using the ROMC Approach 
The dialog subsystem corresponds to the repre- 
sentations and control mechanisms of the ROMC approach. 
The AGDSS terminals will utilize window software to parti- 
tion screen displays combining video, text, and graphics 
from a variety of sources as is illustrated in the following 
example. 
b. Example for the Dialog Subsystem 
Suppose the program manager has just been con- 
fronted with the following problem: the contractor writes 
the government to contest failing a government conducted 
test of a device. The program manager, with the consulta- 
tion of the test and engineering functional managers, must 
decide whether or not the test procedure involved in the 
test is valid or is overspecified. If valid, does a con- 
tractual obligation exist? If so, is it beneficial to the 


government to uphold its position? 
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c. Dialog Sequence 

The above decision is indeed complex, and will 
call for something similar to the following dialog sequence 
to provide the program manager with a set of feasible solu- 
tions to the problen. 

(1) Main Menu. The program manager will ini- 
tialize the AGDSS by selecting "Program Management" from the 
Main Menu which will bring up the Program Management Task 


Menu (see Figure 10). 


Main Menu 


Program Management 
Configuration Management 
Contracting 

Engineering 

Logistics 

Manufacturing 

Program Control 

Test 


1 
2 
3 
4 
5 
6 
7 
8 


Select Option <1-8> 





Figure 10 Main Menu 
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OY 


(2) Program Management Task Menu. The program 
manager selects "Correspondence", "Documentation", and 
"Problem Solving" from the Program Management Task Menu to 
acquire information about and to build a model for a deci- 


sion making process to solve the problem (see Figure 11). 


Program Management Task Menu 


Budget 
Communication 
Correspondence 
Documentation 
Schedules 
Meetings 
Problem Solving 


1 
2 
3 
4 
5 
6 
7 


Select Option <1-7> 





Figure 11 Program Management Task Menu 


(3) Information Windows. The program manager 
will use Information Windows to display the Problem, "What 
if", and references, to the Test Procedure, Specification, 


and Contract (see Figure 12). 
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Figure 12 Information Windows 


(4) Modeling Windows. After reviewing the 
documentation and reflecting on the problem, the program 
manager uses the Modeling Windows to call the "Linear Pro- 
gram" option, to explore the "what if" under consideration 


via "Compute Solution" (see Figure 13). 
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Modeling Windows 


Linear "What if" Opportunity Cost Objective 
Program Function: 


Z = 2X1 + 3X2 
Build a Model 
Revise a Model Constraints: 
Change Data Xl + X2 
Compute Solution Xl + 2X2 
X1 + 3X2 





Figure 13 Modeling Windows 


The independent variable X1 denotes the number of collateral 
test procedures impacted by waiving the given test proce- 
dure. Similarly, X2 is the number of engineering change 
procedures required to make the failed device test compli- 
ant. 

The first constraint limits the number of total proce- 
dures to be implemented, while the latter two constraints 
bound the number of hours for planning and implementation 
respectively. Both X1 and X2 are positive integer values. 

(5) Basic Solutions Window. The program manag- 


er is provided a number of feasible (all variables are 
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positive integer values) and infeasible solutions from which 
to choose. Although it is likely that the infeasible solu- 
tions would be discarded from further consideration, several 
feasible options remain. The program manager will now 
consult with test and engineering to try to determine which 
of these options is most practical. The ensuing discussion 
might result in a less than optimal solution being chosen 
due to factors not modeled in the linear program (see Figure 
14). 

(6) Task Menu. The program manager returns to 
the Program Management Task Menu to set up a meeting via LDN 
computer conferencing, by selecting "Meetings" and "Communi- 


cations" (see Figure 11). 


Basic Solutions Display 


Basic Solutions FEASIBLE/ 
X2 INFEASIBLE 


(0) Feasible 
700 Feasible 
600 Feasible 


Infeasible 





Figure 14 Basic Solutions Display 
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(7) Meetings and Communications Menu. Meetings 
and Communications options are displayed in the Meetings and 


Communications Menu and "Team" and "Video Conferencing" are 


selected (see Figure 15). 









Meetings and Communications Menu 
Se eee ee ee ee 





Meetings 


1 Team 

2 Program Management 
3 Engineering 

4 Logistics 
Communications 

2 Electronic Mail 

2 Video Conferencing 


Select Options <1-4,1-2> 


Figure 15 Meetings and Communications Menu 


(8) Team and Meeting Agenda Menu. The program 
manager selects "Test" and "Engineering" from the options 
listed under "Team" and all of the options under Meeting 
Agenda from the Team and Meeting Agenda Menu. (see Figure 


16). 











Team and Meeting Agenda Menu 


eam 
Configuration Management 
Director of Programs 
Contracting 
Engineering 
Logistics 
Manufacturing 
Program Control 
Test 


T 
1 
2 
3 
4 
5 
6 
7 
8 


Meeting Agenda 


Problem 
Document 
Search 
Modeling 
Solutions 
Decision 





Figure 16 Team and Meeting Agenda Menu 


(9) Conferencing Windows. In Figure 17, the 
test manager (upper left, Perry, 1989, p.44), and the engi- 
neering manager consulting with his engineers (lower left, 
Santo, 1938, p. 54), appear in the video conferencing win- 
dows. The meeting agenda, to be supplemented with other 
text, graphics, etc. appears to the right of the figure. 

The conference will either conclude with a decision on 
whether or not to uphold the government's position, or set 
the stage for another dialog session to try to resolve the 
problem. The video conferencing capability affords the team 


instantaneous face to face contact without requiring them to 
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leave their work areas. By remaining in their work areas, 
team members save time normally taken to gather at a sepa- 
rate location, in addition to the added convenience of 
having immediate access to their work areas, should the need 


arise. 


Conferencing Windows 
Meeting Agenda 


Problem: 
- Contested contractor 
failed test procedure 


Document Search: 
- Test Procedures 
- Specification 


- Contract 


Modeling: 
- Linear Program 
- Solutions 


Decision Alternatives: 

- Amend Test Proce 
dures 

- Uphold Contract 





Figure 17 Conferencing Windows 


2. Data Base Subsystem 
The relational data base incorporates seven primary 
relations that provide task performance from the AGDSS 
terminal corresponding to the task menu discussed in the 
example of Subsection, III Cib. These relations are: 
1. Budget - containing the year and amount. 
2. Schedule - records the type, event, start, and 


finish. 
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3. Meetings - logs the meeting name, date, time and 
location. 

4. Problem - contains the problem number, description, 
priority, and urgency. 

5. Correspondence - tracks correspondence number, to, 
from, date, and subject. 

6. Documentation - includes document number, page(s), 
section, and paragraph. 

7. Communications - holds the medium and link data. 

In addition to the creation, update, and retrieval 
operations, the data base shall have the capability to 
"extract" data from external sources. The extraction proce- 
dure produces local data bases which are subsets, aggre- 
gates, or some combination of the two, which are smaller 
than the source data bases they are derived from. The 
reduced size combined with better indexing, provides for 
faster access times for enhanced system performance. These 
external sources might be within or outside the physical 
confines of the AGDSS. Since the data base is distributed, 
each of the functional area data bases would be considered 
external to the program manager's terminal, yet within the 
confines of the AGDSS. In the example of Subsection III 
Clb, the program manager's data base uses extraction (see 
Figure 18) to obtain the test, specification, and contract 
documentation from test, engineering, and contracting re- 


spectively. These documents are maintained by the respec- 
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documentation from test, engineering, and contracting re- 


spectively. These documents are maintained by the respec- 
tive functional managers, only to eliminate redundancy while 
ensuring data integrity. Extraction is also performed on 
the program manager's internal data base files containing 
program status, model base parameters, and correspondence. 


It is possible. that data extraction could include external 


SOURCE DATA 


Internal 
Program status 






Model Base Parameters 







Correspondence 
Data 
Extraction 
, System 









Dialog 
Component 









Procedures 





Specification 






Contract 


Figure 18 AGDSS Data Base Data Extraction Feature from the 
Program Manager's Perspective 
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connections via a wide area network (WAN), to other partic- 
ipating government agencies and contractors. Since the 
program manager will exchange a great deal of information up 
the chain of command, it will be necessary to provide ex- 
traction between the program manager and his immediate 
superior, the director of programs, who will be connected to 
the AGDSS as well. 
3. Model Base Subsystem 
a. Model Base Description 
The model base will consist of a variety of 
subroutine like building blocks as mentioned earlier which 
can be combined to form models to support the three levels 
of decision making: strategic, tactical, and operational. 
Regardless of the level invoked, the same basic steps for 
exercising the model base subsystem occur via links to the 
dialog subsystem and data base subsystem. Intermodel links 
also exist between the three levels when called upon. 
First, the model is selected and assembled from the basic 
building blocks stored in the model base. Once assembled, 
the model loads the necessary parameters requested by the 
user from the data base. Next, the model is executed, 
granting the user the option to interrupt the process at any 
time to check intermediate or final results, or to change 


parameters and/or sequencing. Upon completion of execution, 
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the model places the results in the data base and signals 
the user that it has finished execution. 
b. Example for the Model Base Subsystem 

Following the example from Subsection III Clb, 
Figure 19 shows the three levels of modeling involved in 
deciding what to do about the contractor's failure of a 
government test procedure. For each level, the first column 
shows the inputs, the second column shows the extracted data 
base, and the third column shows the linear programming mod- 
el employed for that level. 

The director of programs strategic model and the test 
and engineering operational models are separately linked to 
the program management tactical model. The director of 
programs having updated the funding data with the latest 
Program Objective Memorandum (POM) figures, is concerned 
about the consequences of decisions at subordinate levels 
which affect major expenditures. The director, after a 
video conference with the program manager, may decide to cut 
or cancel the program (which might obviate the problem at 
the subordinate levels), in light of long range funding and 
the program's status and priority measured against other 
programs. Recall the "what if" opportunity cost objective 
function of the tactical model from the dialog example, 
Subsection III Clb. This model's data is updated by a 


contract letter which establishes the objective of minimiz- 
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ing the cost to the government of upholding the test proce- 
dure, and subjecting the government to contractor claims, 
versus changing the procedure and any collateral procedures 
to accommodate testing. The proposed test procedure and 
design changes fed into the data base, drive the operational 
model, which supports the tactical model by providing the 
constraints to the latter model's objective function. These 
constraints are derived by exploring possible answers to the 
basic questions. First, was the test procedure valid or 
over specified? If valid, does a contractual obligation 
exist on the contractor's part? Finally, if so, how benefi- 
cial is it for the government to pursue consideration from 
the contractor? 
4. Outputs 

While the AGDSS is constantly processing input and 
output during the dialog sequences, it is also accomplishing 
other mundane and labor intensive tasks with much greater 
efficiency than the manual methods relied upon currently to 
prepare and process program documentation. In the example, 
the program manager retrieves excerpts from the test, speci- 
fication, and contract documentation, which is maintained by 
the functional managers via the AGDSS. In addition, the 
AGDSS will record dialog sessions, video conference meeting 
minutes, and other historical information. A serious short- 
coming of meeting minutes currently, is the tendency for the 


person recording minutes to omit or misinterpret, key infor- 
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mation during a meeting or while translating a tape record- 
ing of the meeting. Furthermore, the minutes review process 
can take days, even weeks, requiring preparation, distribu- 
tion, review and correction. By the time the minutes become 
available for review, the events that transpired are no 
longer fresh in the minds of those reviewing the minutes, 
making it nearly impossible to judge whether or not the 
minutes as recorded are both accurate and complete. Incom- 
plete and/or inaccurate minutes are a prime source of commu- 
nication breakdown and its related problems (see Chapter I, 
p. 2). The AGDSS will preclude human error in recording the 
minutes and the expensive and time consuming review process 
which is required to compensate for that error. 

The program manager as well as the functional managers 
invest significant amounts of time preparing reports and 
briefings to the deputy for programs. Much of their effort 
would be replaced by the AGDSS. Relieved of the mundane and 
time consuming tasks associated with preparing view graphs 
and typing reports, the managers can devote their time to 
managing their functional areas, with the only burden being 
that of maintaining the AGDSS data base, from which both 
timely and informative reports and briefings will be de- 
rived. Thus the untimely and/or uninformed decision (see 
Chapter I, p. 3) is a less likely result of AGDSS generated 


reports and briefings. 
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D. SUMMARY 

The foregoing example demonstrates the advantage a deci- 
sion support system can afford to the acquisition group in 
decision making. Through the dialog subsystem, the director 
of programs, program manager, and functional manager can 
effortlessly contact each other and obtain required program 
document references without filtering important information. 
Insights provided by these references can be objectively 
modeled to arrive at a set of timely and informed alterna- 
tive decisions. Furthermore, dialog sessions, such as the 
example, can be archived for future reference, an invaluable 


capability which has no equal in the non-DSS world. 
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1. SCOPE 


1.1 Scope. This specification establishes the performance and 
interface requirements for the AGDSS. 


2. REFERENCED DOCUMENTS 
2.1 GOVERNMENT DOCUMENTS 
SPECIFICATIONS: 

Military 


SS-CSOC-00001B System Specification for the 
84 Apr 16 Consolidated Space Operations Center 


STANDARDS: 
rederal 


DOD-5200.28-STD Department of Defense Trusted Computer 
December 1985 System Evaluation Criteria 


Military 


AFOSH STD 127-64 Data Processing Facilities 
79 Mar 03 

IMC 80-1 

81 Jan 19 


MIL-STD-454H Standard General Requirements for Elec- 
82 Jul 30 tronic Equipment 

Notice 1 

82 Sep 01 


MIL-STD~490A Military Standard Specification Practices 
85 Jun 4 


2.2 NON-GOVERNMENT DOCUMENTS 

SPECIFICATIONS: Reserved 

STANDARDS: Reserved 

OTHER PUBLICATIONS: 

Bui, T., and Jarke, M., “Communications Requirements for Group 
Decision Support Systems," paper presented at the Nineteenth 


International Conference on System Sciences, University of 
Hawaii, Honolulu, Hawaii, January 1986. 
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Bui, T., Jarke M., and Shakun, M.F., "Non-Cooperation in Group 
Decision Support Systems Many Problems and Some Solutions," 


SCIMA, Journal of Management Science and Cybernetics, V. 18, Nos. 
1-2, pp. 51-63, 1989. 


Chorafas, D.N., Computer Networks for Distributed Information 
Systems, Petrocelli Books Inc., 1980. 


NCSC-TG-005 Trusted Network Interpretation of the 

31 July 1987 Trusted Computer System Evaluation Criter- 
ia 

NCSC-TG-008 A Guide to Understanding Trusted Distribu- 

15 December 1988 tion in Trusted Systems 


Sprague, R. H., and Carlson, E. D., Building Effective Decision 
Support Systems, Prentice Hall, 1982. 


3. REQUIREMENTS 
3.1 SYSTEM DEFINITION 


This specification defines the performance and interface 
requirements for the Acquisition Group Decision Support Systen 
(AGDSS). The AGDSS combines such key technologies as locc. area 
networks, word processing, graphics, data base management, and 
video conferencing, which can free acquisition team members of 
mundane paperwork, and afford them extraordinary decision making 
capabilities. These capabilities promise to result in more 
timely and better informed decisions. 


3.1.1 General Description 


The AGDSS is composed of four subsystems: 
Communications, 
Dialog, 
Data Base, and 
Model Base. 
These subsystems are discussed below. 


3.1.1.1 Communications Subsystem (CS) 


The CS provides the local area network (LAN) network archi- 
tecture functions, interfaces, and protocois (Chorafas, 1980, 
p.74). In addition, the CS indicates to individual DSS not only 
how to communicate, but also what type of information should be 
exchanged. (Bui and Jarke, 1986, p. 11) 


3.1.1.2 Dialog Subsystem (DS) 


Dialog between the user and the DSS is accomplished via the 
DS. The DS consists of facilities to perform the man-machine 
interface of the AGDSS. 


45 





SS-AGDSS-00001A 
09 April 1990 


3.1.1.3 Data Base Subsystem (DBS) 


The DBS contains the archives for documentation as well as 
parameters for the model base. 


3.1.1.4 Model Base Subsystem (MBS) 


The MBS utilizes the DBS manipulation language to assemble 
the necessary model building blocks into models for use by the DS 
and to execute those models with parameters input via the DS. 


3.1.2 Mission 

The mission of the AGDSS is to provide acquisition team 
integrity and the necessary information processing capacity, to 
mitigate the impact of the adverse effects of communication 


breakdown and filtering of information, on acquisition decision 
making. 


3.1.3 Threat 


The system is subject to the threat described in NCSC-TG- 
008, Version-1. 


3.1.4 System Diagrams 
3.1.4.1 Functional Flow Diagrams 


The top functional flow diagram for the system is shown in 
Figure 3-1. 
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Figure 3-1. AGDSS Top Flow Diagram 


3.1.4.2 Specification Tree 


The specification tree for the system is shown in 
Figure 3-2. 
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Figure 3-2. AGDSS Specification Tree 
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3.1.5. Interface Definition 


For the purposes of this specification an interface is 
defined as a functional relationship, physical connection, or 
software/information transfer between two or more equipment/comp- 
uter program entities within a system or between a system and 
entities external to it. 


AGDSS interfaces are comprised of external, intersubsysten, 
and intrasubsystem categories. Interfaces existing between AGDSS 
entities and entities external to the AGDSS are defined to be 


external. Intersubsystem interfaces are defined to exist between 
AGDSS subsystems and between AGDSS subsystems and the Facilities 
Segment. Intrasubsystem interfaces are defined as those which 


exist between entities within an AGDSS subsystem (e.g., elements, 
subelements, assemblies, subassemblies, components, parts). 


3.1.5.1 Intersubsystem Interfaces 


AGDSS intersubsystem interfaces excluding the Facilities 
Segment are shown in Figure 3-3. The DS provides the MBS with 
model parameters and receives model results from the MBS via the 
CS. The model building blocks are shown leaving the DBS and 
entering the MBS. Finally, double-headed arrows indicate that 
documentation and queries require full duplex communication ties 
between the DS and DBS. 


3.1.5.2 External Interfaces 
AGDSS external interfaces are shown in Figure 3-’ 


3.1.5.3 Intrasubsystem Interfaces 


Intrasubsystem interface requirements are defined in the 
lower-tier (SSS & SES) documents and the facilities intrasegment 
requirements are defined in the SD document of the specification 
tree. 

3.2 CHARACTERISTICS 
3.2.1 Performance Characteristics 


3.2.1.1 Interoperability 


The interoperability of the AGDSS subsystems will be pro- 
vided by the intersubsystem interfaces (see paragraph 3.1.5.1). 


3.2.2.1 Facilities 
The AGDSS Facilities Segment shall be as specified in the 
Facility Specification (FS) SD-AGDSS-00020. 
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Communications Subsystem 
Provides the local area network (LAN) network architecture 


functions, interfaces, protocols, and controls both how 
and what type of information is exchanged. 













Pp R D 10) Q D B B P R 
a e fe) u u ro) u u a 2 
r Ss c e e c i i r s 
a u u xr r u 1 1 a u 
m 1 m i z m da da m 1 
e t e e e e i i e t 
t s n s s n n n t Ss 
e t t g g e 
r a a r 
s t t B B S 
i i 1 1 
ro) ro) fa) ro) 
n c c 
k k 
s Ss 
Dialog Data Base Model Base 
Subsystem Subsystem Subsystem 








- Create Files 
- Update Files 
- Conduct Queries 
Data Extraction 


- Action Language 

- Display or 
Presentation 
Landuage 

- Knowledge Base 


- Construct Models 
- Update Models 
- Execute Models 





Figure 3-3. AGDSS Intersubsystem Interfaces 








Director of Programs 


Program Manager External Agencies 
L 


Functional Managers 
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3.2.2.2 Electrical Power 


The AGDSS shall be provided with facility power. 


3.2.3 Reliability 


AGDSS mission reliability is defined as the probability of 
successful AGDSS equipment support of a mission for a specified 
time period. Quantitative reliability requirements are derived 
from the mean time between critical failures (MTBCF) of the 
functional equipment and the time duration over which the reliab- 
ility is specified. 


a. The following guidelines shall be used in interpreting 
the requirements in this section and in 3.2.4 and 3.2.5: 


(1) The reliability, maintainability, and availability 
parameters defined in this specification do not 
include any impact due directly or indirectly to 
actual threats, operator errors, or software. 


(2) Redundancy may be used to obtain the required 
reliability figures if the redundant element is on 
line or is substituted for a failed element in a 
non-interrupting manner, or if automatic or manual 
switch-over can be effected in a period of time and 
in a manner that allows full mission continuance. 


(3) AGDSS equipment shall provide levels of reliabili- 
ty, availability, and maintainability sufficient to 
meet the applicable requirements of the AGDSS 
subsystems. 


3.2.3.1 Subsystem and Facilities Segment Reliabilities 


The AGDSS Subsystems and Facilities Segment shall have 
reliabilities as described below. 


3.2.3.1.1 Communications Subsystem Reliability. The Communica- 
tions Subsystem shall properly switch, transmit, or receive data 
or voice/video between any two points in the AGDSS communications 
network, with a reliability of 0.9995 for a period of 30 minutes. 


3.2.3.1.2 Dialog Subsystem Reliability. TBD. 


3.2.3.1.3 Data Base Subsystem Reliability. TBD. 


iw 


.2.3.1.4 Model Base Subsystem Reliability. TBD. 
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3.2.3.1.5 Facilities Segment Reliability. The AGDSS shall be 
provided commercial power, environmental control, and backup 


power through the Facilities Segment. The Facilities Segment 
shall have the following reliabilities: 


a. The reliability of the environmental systems (temper- 
ature, humidity, etc.) shall be at least 0.99998 for a 
period of 8 hours. 


b. The reliability of the backup power system shall be at 
least 0.9989 for a period of 24 hours. 


3.2.3.2 Mean Time Between Critical Failures 


A critical failure is defined as any equipment failure 
causing an unscheduled interruption which prohibits a system from 
successfully completing its function within the allocated time. 
The Mean Time Between Critical Failures (MTBCF) for AGDSS or for 
any AGDSS subsystem shall meet the following requirements: 


a. The MTBCF shall be consistent with the reliability 
requirements specified in 3.2.3 and 3.2.3.1. 


b. The MTBCF shall be determined using actual component or 
device failure rates. When such information in not | 
available, the MTBCF may be determined analytically. 


c. The MTBCF may be achieved through the application of 
redundant equipment, provided it complies with 3.2.3a. 


3.2.4 Maintainability 

Preventive maintenance and planned ccnfiguration changes are 
classified as scheduled maintenance. The AGDSS shall be designed 
to meet the foliowing maintainability requirements: 

a. Maintainability shall conform to the reliability re 


quirements of 3.2.3, 3.2.3.1, and availability require- 
ments of 3.2.5. 


b. Maintainability shall be: 


(1) Predicated on the necessity of continuous opera- 
tions 


(2) Consistent with the logistics requirements in 3.5 


c. All scheduled maintenance shall be such that it does not 
interfere with the support of critical operations. 


ad. Life-cycle costs shall be a major consideration in 
determining maintainability. 
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3.2.4.1 Mean Time to Restore 


Mean Time to Restore (MTR) is the average time required to 
restore a function lost due to equipment failure. 


a. MTR shall include both switch-over and restoration of 
the system to the minimum configuration required to 
support a mission. 


b. MTR may include any or all of the following steps: 
isolation, disassembly, reassembly, re-boot, and check 
out. The duration starts at the report of system 
malfunction and ends at completion of system restora 
tion. 


3.2.4.2 Mean Time Between Maintenance Actions 


Mean Time Between Maintenance Actions (MTBMA) is the total 
number of system life units divided by the total number of 
maintenance actions (preventive and corrective) during a stated 
period of time. The MTBMA for each subsystem shall be (TBD). 


3.2.4.3 Maximum Continuous Downtime 


The 90th percentile of downtime distribution of a given 
AGDSS function is defined as Maximum Continuous Downtime (Mmax). 
Assuming that all resources for support of a given function are 
available at the start of the downing event and that maintenance 
personnel are on site, Mmax for both scheduled and unscheduled 
maintenance shall not exceed the following values. 


Function Mmax MTBMA 
a. Communications Subsystem 60 minutes (TBD) 
b. Dialog Subsystem 30 minutes (TBD) 
c. Data Base Subsystem 60 minutes (TBD) 
d. Model Base Subsystem 60 minutes (TBD) 


3.2.5 Availability 


Availability (Ao) is the probability an item is in an 
operable and committable state at the start of a mission, when 
the mission is called for at a random time. Availability re- 
quirements are established in terms of MTBCF, MTR, and Scheduled 
Maintenance (SM): 


Ao = MTBCF /(MTBCF + MTR + (SM * MTBCF / SM INTERVAL) } 
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SM is the average of total downtime per maintenance inter- 
val, resulting from preventive maintenance, overhaul, and other 
predetermined maintenance procedures during which the system 
cannot perform its mission. The maintenance interval is a 
periodic time interval encompassing both the downtime durations 
and the elapsed time between scheduled maintenance actions. 


When scheduled maintenance can be scheduled around the 
required subsystem function it does not affect the availability 
and the term involving SM is correspondingly zero in the availa- 
bility equation. 


a. The equipment configuration required to support a real- 
time dialog session (single or multiple user/system in- 
teraction without video conferencing) shall have an 
availability equal to 0.995. 


b. The equipment configuration required to support a real 
time dialog session with video conferencing shall have 
an availability equal to 0.990. 


c. The Uninterruptible Power Supply shall have an availa- 
bility of at least 0.99999 for regulation and smoothing 
functions and 0.99999 for uninterrupted power supply 
functions. 


3.2.6 Environmental Conditions 


Environmental conditions and requirements (physical and 
space) design criteria for AGDSS equipment and facilities shall 
be as specified in the Facility Specification (FS), SD-AGDSS- 
00020. 


3.2.7 Security 


The AGDSS shall provide a secure operational environment to 
promote mission assurance and survivability, and to protect 
classified information from compromise. 


3.2.7.1 Information Security 


The AGDSS shall provide capabilities to protect classified 
information against unauthorized modifications or disclosure 
commensurate with the level of classification assigned under 
varying conditions which may arise in connection with its use, 
dissemination, storage, movement or transmission, and destruc- 
tion. 
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3.2.7.2 Communications Security 


The AGDSS shall be designed to provide communications 
security (COMSEC) such that classified information transmitted . 
over internal and external telecommunications networks, systems, 
and circuits shall be protected. 


3.2.7.3 TEMPEST Security 


AGDSS equipment shall provide TEMPEST protection to control 
compromising emanations compatible with, and not redundant to, 
the TEMPEST protection provided by the Facilities Segment. 


3.2.7.4 Automated Data Processing System Security 
AGDSS automated data processing shall: 


a. Have an explicitly defined set of access controls based 
on classification, user clearance, and established need 
to know. 


b. Provide users (1) access to all the information for 
which they are authorized, and (2) deny access to 
information for which they are not authorized. 


3.3 DESIGN AND CONSTRUCTION 


Newly designed equipment shall be designed and constructed - 
in accordance with high-quality commercial practices except where 
higher quality practices are specified. The AGDSS shall utilize, 
to the maximum extent practical, equipment and software already 
acquired and/or developed for acquisition office automation, 
consistent with achieving cost-effective design and development 
functions and maintaining compatibility, interoperability, and 
supportability at the AGDSS. 


3.3.1 Materials, Processes, and Parts 





Materials, processes, and parts shall meet the following 
requirements: 


a. Commonality in materials, processes, and parts shall be 
a major criterion in their selection to minimize the 
variety of parts, related tools, and test equipment 
required in the fabrication, installation, and mainten- 
ance of the system. 


b. The materials, processes, and parts selected shall be of 
sufficient proven quality to allow the equipment to meet 


54 





SS-AGDSS-00001A 
09 April 1990 


the functional performance, reliability, and strength 
requirements during the applicable life cycle, including 
all environmental degradation effects. 

3.3.1.1 Parts Standardization 


Standardized off-the-shelf parts shall be used wherever 
compatible with interoperability and life-cycle cost constraints. 


3.3.2 Safety 

Systems safety engineering principles to provide protection 
against personal injury and/or damage to equipment shall be 
applied throughout the design, development, manufacture, test, 
installation, and checkout of the AGDSS equipment and facilities 


in accordance with MIL-STD-454H where applicable. Occupational 
Safety shall be in accordance with AFOSH STD 127-64. 


3.3.3 Expandability 


The AGDSS shall be developed such that upgrading of capabil- 
ities may be accomplished without degrading on-going operations. 


3.4 DOCUMENTATION 
AGDSS documentation requirements are as follows: 
a. Documentation of new and existing equipment and software 
shall support design, testing, inspection, installation, 


operation, and maintenance. 


b. Existing documentation shall be utilized where practical 
when software or equipment components are replicated. 


c. The term software shall include firmware. 
3.4.1 Specifications 

The AGDSS specification tree, Figure 3-2, shall control 
lower tier specification trees for system subsystems and the 
Facilities Segment and for Configuration Items (CIs) and Computer 
Program Configuration Items (CPCIs). 


3.4.2 Drawings 


Drawings shall be provided as follows: 
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3.4.2.1 Program Peculiar Items 


New design shall be supported with equipment drawings and 
listings sufficient to provide remanufacture, provisioning, 
fabrication, installation, and reprocurement activities. 


3.4.2.2 Off-the-Shelf or Commercial Equipment 


Drawing information shall be sufficient to support main- 
tenance and repair activities and to permit reprocurement in 
accordance with subsystem/segment contracts. 


3.4.3 Technical Manuals 


Operation and maintenance manuals for equipment and software 
shall incorporate levels of detail compatible with AGDSS staf- 
fing. 


3.5 LOGISTICS 


3.5.1 Logistics Support 


The AGDSS shall include the following logistics considera- 
tions. 


a. The AGDSS shall be designed with supportability as a 
major criterion. 


b. Provisions for a maintenance program shall be made to 
allow flexibility and trade-offs between maintainability 
and reliability. 


3.5.2 Maintenance 


AGDSS maintenance considerations shall include the follow- 

ing: 

a. Design shall accomodate maximum utilization of component 
modularity to enhance removal and replacement mainten- 
ance action on the installed equipment and minimize 
downtime. 


b. All Line Replaceable Units (LRUs) shall be readily 
accessible to ease maintenance action. 


c. AGDSS maintenance shall be consistent with time con- 
straints imposed by mission schedules. 


ad. The AGDSS design shall be compatible with technician 


level skill requirements for maintenance. The mainten- 
ance and skill level requirements will be: 
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(1) Determined so that organizational/intermediate 
maintenance can be performed down to the subassem- 
bly level. Design will accommodate depot level 
maintenance to the part level. 


(2) Determined by Logistic Support Analysis and Repair 
Level Analysis 


(3) Established in accordance with the AGDSS mainten- 
ance concept. 


e. Design shall accomodate the employment of a mix of 
military, in-service civilians, and contractor personnel 
to carry out on-equipment and off-equipment maintenance. 


f. The AGDSS system shall be designed to incorporate 
maximum use of automated, built-in test/built-in fault 
isolation capability to diagnose and isolate failures to 
the designazed LRU level. 


g. Where automated or manual support equipment is required, 
government inventory items, modified inventory items, or 
commercial off-the-shelf items shall be used to the 
maximum extent with new design kept to a minimun. 


3.5.2.1 Testability 


Provisions shall be made for fault isolation tests using 
automated built-in fault isolation capability which identifies 
the failed Line Replaceable Unit. 


3.5.2.1.1 Test and Evaluation Support. Each AGDSS subsystem 
shall provide the capility to support individual and integrated 
testing during Development Test and Evaluation (DT&E), and 
integrated testing during Initial Operational Test and Evaluation 
(IOT&E), and Follow-On Operational Test and Evaluation (FOT&E). 


3.5.2.2 Scheduled and Unscheduled Maintenance 


The AGDSS design shall accommodate the following approach to 
scheduled and unscheduled maintenance: 


a. Scheduled preventive maintenance and engineering changes 
without interfering with critical operations support 


b. Unscheduled corrective maintenance including actions 


required to inspect, service, calibrate, and repair 
equipment. 
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3.5.3 Supply 


Supply requirements shall be integrated into the development 
phase of new or modified equipment and identified during the 
acquisition of commercial equipment to establish and provide a 
supportable, cost-effective logistics system for all subsystems 
and the Facilities Segment of the AGDSS, compatible with the 
government supply system. 


3.6 PERSONNEL AND TRAINING 
3.6.1 Personnel 
Personnel considerations shall include the following. 


a. The AGDSS shall be designed and built to be operated and 
maintained principally by military personnel not ex- 
pected to have extensive scientific or engineering 
training. In addition, DoD civilian and contract 
civilian personnel will be used. 


b. Personnel not possessing data processing and/or computer 
maintenance backgrounds, shall be provided the necessary 
prerequisite training. 

3.6.2 Training 

The AGDSS shall provide training capabilities for operations 
personnel and maintenance personnel to the performance levels 
required by AGDSS operations and maintenance. Training shall be 
consistent with requirements defined in the AGDSS Master Training 
Plan. 
3.6.2.1 Operations 
3.7 FUNCTIONAL AREA CHARACTERISTICS 


3.7.1 Communications Subsystem (CS) Operations 


The CS shall provide an Application Element (AE), a Presen- 
tation Element (PE), and a Network Link Physical Element (NLPE). 


3.7.1.1 Application Element 


The AE functions are described in the following paragraphs 
which contain excerpts from Bui and Jarke, 1986, p. 16. 


3.7.1.1.1 Group Norm Monitor. The group norm monitor shall 
provide a flexible and adjustable mechanism for monitoring 
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communications transfers between individual DSS to predict in 
advance the definition of group decision making frameworks. 


3.7.1.1.2 Group Norm Filter (GNF). The GNF shall enforce the 
defined protocols of the Group Norm Constructor (GNC) whenever a 
communication activity is triggered by the AGDSS users. When a 
data transfer is requested, the GNF shall: 


a. Check whether or not the communication desired corre- 
sponds to the preset protocol. 


b. If the request is in accordance with the protocols, it 
shall be transferred to the next communications routine. 


c. Otherwise, the GNF shall notify the user of the viola- 
tion and offer him/her the current communications 
protocols pattern, if requested. 


3.7.1.1.3 Invocation Mechanism (IM). The IM shall provide for 
modification cf the communications protocols previously set via 
the GNC. The IM shall: 


a. be triggered by a user's request 


b. determine when and how to convene the other users to 
debate and vote on the motion. 


3.7.1.2 Presentation Element 


The PE function is described in the following paragraph 
containing excerpts from Bui and Jarke, 1986, p. 16. 


3.7.1.2.1 DSS-to-AGDSS Document Formatter (DADF). The DADF 
shall contain to the extent practical, presentation protocols for 
any possible type of data exchange in a group decision situation. 
Examples of such protocols are those related to data structures 
that are shared between the individual DSS model components and 
the AGDSS model component. For instance, in a voting procedure, 
data must be compressed before being reported to individual 
members. 


3.7.1.3 Network Link Physical Element 


The NLPE shall perform the functions of layers 1-5 of the 
Open Systems Interconnection (ISO) Reference Model. 


3.7.2 DS Operations 


The DS shall provide the following elements as described in 
the following paragraphs containing excerpts from Srrague and 
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Carlson, 1982, pp. 214-216: an Output Formatter Element (OFE), 
an Output Constructor Element (OCE), a Device Output Functions 
Element (DOFE), a Device Driver Element (DDE), a Device Input 
Functions Element (DIFE), an Input Formatter Element (IFE), a 
Response Constructor Element (RCE), and a Dialog Data Structure 
Manager Element (DDSME). The values and attributes associated 
with tne function of these elements shall not be specific to any 
interface hardware, so as to permit the dialog subsystem to 
support a variety of hardware. 


3.7.2.1 Ouput Formatter Element 


The OFE shall translate commands and data into data struc- 
tures containing the values (e.g., text strings) and attributes 
(e. g., color, position, size), describing the output represent- 
ations (how the values are to be displayed). 


3.7.2.2 Output Constructor Element 


The OCE shall translate the dialog data structure into 
commands to create an output representation on one or more 
devices. 


3.7.2.3 Device Output Functions Element 


The DOFE shall generate device-specific commands to create 
outputs on one or more specific devices. 


3.7.2.4 Device Driver Element 


The DDE shall send the DOFE commands to the device, wait for 
user inputs, or request user inputs if the output message is an 
interrupt rather than commands to generate a representation. 

When user inputs are received, the DDE shall buffer the inputs 
and send the inputs to the device input functions element. 


3.7.2.5 Device Input Functions Element 


The DIFE shall translate specific inputs into device inde- 
pendent inputs. 


3.7.2.6 Input Formatter Element 


The IFE shall translate the user's input into a set of 
action-object pairs. The action describes the user's input 
action (e.g., keyboard keystroke). The object designates which 
object in the output representation that was affected by the 
action (e.g., new value or attribute for a menu item). 
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3.7.2.7 Response Constructor Element 


The RCE shall use a set of action-object pairs to create 
commands and data for the other components of the DSS e.g., 
update a data base field corresponding to the field in the output 
representation into which the user had just typed a new value. 


3.7.2.8 Dialog Data Structure Manager Element 


The DDSME shall store and retrieve data used by the dialog 
component, such as the data structure that describes the output 
representation. 


3.7.3 DBS Operations 


The DBS shall provide data base management system (DBMS) 
operations utilizing optimization and a data extraction design. 
Optimization techniques such as automatic file reorganization, 
access path optimization, and operation batching shall be em- 
ployed to increase the performance of the operations. Data 
extraction shall provide for interfacing a variety of AGDSS 
source data bases with each other. The DBMS operations are 
described in the following paragraphs which contain excerpts from 
Sprague and Carlson, 1982, pp. 236-239: a Dictionary Element 
(DE), a Creation and Deletion Element (C&DE), an Update Element 
(UE), a Query Element (QE), a View Element (VE), a Protection 
Element (PE), a Sharing Element (SE), and a Recovery Element 
(RE) . 


3.7.3.1 Dictionary Element 


The DE shall support data base dictionary functions such as 
adding new entries, deleting entries, retrieving information on 
the entries, and maintaining multiple indices (e.g., data name, 
date created, responsible organization). The DE functions shall 
be integrated with the other DBS operations such that for exam- 
ple, deleting an item from the dictionary should result in 
deleting it from the data base. 


3.7.3.2 Creation and Deletion Element 
The C&DE shall support addition and subtraction of objects 


in the data base in accordance with the tvpe of creation and 
selection operations permitted by the data base model. 


3.7.3.3 Update Element 


The UE shall permit values to be replaced in the data base. 
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3.7.3.4 Query Element 


The QE shall support the selection and manipulation of 
records and fields in the data base. 


3.7.3.5 View Element 


The VE shall provide customized data structures (data bases, 
records, or fields) by defining a subset, aggregation, or other 
combination of the data base. 


3.7.3.6 Protection Element 


The PE shall provide restrictions to control unauthorized 
usage of DBMS functions. 


3.7.3.7 Sharing Element 


The SE shall determine how many users can have simultaneous 
access to the data base. If sharing is permitted, the SE shall 
provide locking functions to prevent users from accessing incon- 
sistent data and preventing "deadlock" (preventing each other 
from proceeding). 


3.7.3.8 Recovery Element 





The RE shall provide the capability to restore the data base 
to a consistent state after either a hardware (disk) failure or 
after a software (program) failure. The RE shall checkpoint and 
log the data base on a separate file for recovery purposes. In 
the event of a failure, the data base shall be recovered by 
applying the sequence of operations in the log (create, update, 
and delete) to the most recent checkpoint. 


3.7.4 MBS Operations 


The MBS shall provide a model base management system (MBMS) 
analogous to a DBMS, with the following elements as described in 
the following paragraphs which contain excerpts from Sprague and 
Carlson, 1982, p. 262: a Generation Element (GE), a Restructure 
Element (RE), an Update Element (UE), and a Report Generation- 
Inquiry Element (RG-IE). 





3.7.4.1 Generation Element 
The GE shall provide a mechanism for building or generating 


models. This mechanism shall be designed to accommodate change in 
user needs as well as technology. 
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3.7.4.2 Restructure Element 


The RE shall provide a way to redefine or restructure a 
model in response to changes in the modeled situation. 


3.7.4.3 Update Element 


The UE shall provide a procedure for updating a model in 
response to change in data (e.g., a revised parameter estimate 
without change in structure). 


3.7.4.4 Report Generation-Inquiry Element 


The RG-IE shall provide for operation of the model to obtain 
the decision support desired. Alternative forms may be: 


a. Periodic run of a well-established model 

b. Special results from an ad hoc model 

c. Use of data analysis models 

ad. Iterative rerun of a model or set of models 


e. The sequential run of a set of interrelated models 
according to a predefined procedure. 


3.8 PRECEDENCE 
3.8.1 Conflicts 

In the event of conflict between the documents referenced 
herein and this specification, the contents of this specification 
shall prevail. Unresolved conflicts shall be directed to the 
contracting officer or delegated representative for resolution. 


4. QUALITY ASSURANCE PROVISIONS 


Quality assurance provisions shall be performed in a manner 
consistent with the requirements of this specification. 


5. PREPARATION FOR DELIVERY 
Not Applicable. 
6. NOTES 


Reserved. 
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